Electronic data interchange (EDI) is a structured way of exchanging data electronically, directly between computer systems, according to particular standards. EDI standards set out the proper format, characters, and data elements to be used in EDI communication. There are several different standards currently being used throughout the world and others may be developed from time to time. EDI communications often occur between trading partners, such as individuals, businesses, government organizations, charities, and other organizations and entities which have a need to exchange data directly between computer systems. The relationship between trading partners may be that of buyer and seller, but may also be that of merchant and warehouse, merchant and shipper, supplier and third party supplier, collaborators of various sorts, or any other relationship for which the members find electronic transmission of data advantageous. EDI communications may also take place between computer systems owned by a single organization; that is, the EDI communications may include internal communications, as well as external communications.
While EDI communications are often used among businesses, EDI communications are not so limited. They may include, for example, scientific information, medical information, transportation information, engineering information, or any other communication where the exchange of data directly between computers is likely to be useful. The EDI transmission of the data commonly uses any convenient method and may include internet as well as non-internet transmission, either via hard wire or wireless methods.
Even using a common standard, implementation of EDI format differs among trading partners. While an invoice, for example, may contain several types of data as a minimum in order to comply with an EDI standard, the invoices of different entities may vary considerably according to their particular industry and needs. Thus, transmitting a first trading partner's EDI data to a second trading partner, and displaying the data correctly in the second trading partner's format, can be problematic.
In addition, while working out the difficulties of communication between just two trading partners might be a limited problem, large organizations may have not just one but dozens, hundreds, or even thousands of trading partners. And each of the dozens or hundreds of trading partners may themselves have one, two, dozens, hundreds, or thousands of trading partners. With each having slightly different arrangements of EDI documentation, EDI communication becomes more complex. The issue is also complex for using an EDI multi-tenant platform, which hosts and facilitates EDI communication among many trading partners.
One approach to this problem is described in the Wikipedia entry for “Electronic Data Interchange”:                For an “inbound” document the EDI solution will receive the file (either via a Value Added Network or directly using protocols such as FTP or AS2), take the received EDI file (commonly referred to as a “mailbag”), validate that the trading partner who is sending the file is a valid trading partner, that the structure of the file meets the EDI standards and that the individual fields of information conforms to the agreed upon standards. Typically the translator will either create a file of either fixed length, variable length or XML tagged format or “print” the received EDI document (for non-integrated EDI environments). The next step is to convert/transform the file that the translator creates into a format that can be imported into a company's back-end business systems or ERP. This can be accomplished by using a custom program, an integrated proprietary “mapper” or to use integrated standards based graphical “mapper” using a standard data transformation language such as XSLT. The final step is to import the transformed file (or database) into the company's back-end enterprise resource planning (ERP) system.        For an “outbound” document the process for integrated EDI is to export a file (or read a database) from a company's back-end ERP, transform the file to the appropriate format for the translator. The translation software will then “validate” the EDI file sent to ensure that it meets the standard agreed upon by the trading partners, convert the file into “EDI” format (adding in the appropriate identifiers and control structures) and send the file to the trading partner (using the appropriate communications protocol).        In EDI terminology “inbound” and “outbound” refer to the direction of transmission of an EDI document in relation to a particular system, not the direction of merchandise, money or other things represented by the document. For example, an EDI document that tells a warehouse to perform an outbound shipment is an inbound document in relation to the warehouse computer system. It is an outbound document in relation to the manufacturer or dealer that transmitted the document.”        
But even using the approach disclosed above, for outgoing documents, the translator must understand what data to retrieve from locations within the database, or ERP file used by the transmitting trading partner, to transform it into a first EDI format used by the transmitting trading partner. For incoming documents, the translator must understand how to take incoming EDI data in the first EDI format used by the transmitting trading partner and convert it into a second EDI format used by a receiving trading partner. Both processes can be complex problems, requiring coding specific to the trading partner's format. If the translator retrieves data and formats it incorrectly, error can result.
As a part of or after translation from a first EDI format, many systems push the data into a database. When the data is translated into a second trading partner's version of EDI, the translator must know which data to retrieve from the database.
Alternatively, in some cases, such as with a first trading partner of significant size, the second trading partner will be forced to adopt the first trading partner's version of EDI, even if that version is a poor fit for the second trading partner's business.